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Abstract —We present Buzz, a novel programming language 
for heterogeneous robot swarms. Buzz advocates a compositional 
approach, offering primitives to define swarm behaviors both 
from the perspective of the single robot and of the overall 
swarm. Single-robot primitives include robot-specific instructions 
and manipulation of neighborhood data. Swarm-based primitives 
allow for the dynamic management of robot teams, and for 
sharing information globally across the swarm. Self-organization 
stems from the completely decentralized mechanisms upon which 
the Buzz run-time platform is based. The language can be 
extended to add new primitives (thus supporting heterogeneous 
robot swarms), and its run-time platform is designed to be 
laid on top of other frameworks, such as Robot Operating 
System. We showcase the capabilities of Buzz by providing 
code examples, and analyze scalability and robustness of the 
run-time platform through realistic simulated experiments with 
representative swarm algorithms. 

Index Terms —distributed robot systems, control architectures 
and programming, swarm robotics, swarm engineering 


I. Introduction 

S WARM robotics systems jf| are envisioned for large- 
scale application scenarios that require reliable, scalable, 
and autonomous behaviors. Among the many hurdles towards 
real-world deployment of swarm robotics systems, one of 
the most important is the lack of dedicated tools, especially 
regarding software |2|. In particular, one problem that has 
received little attention in the literature is programmability. 
The current practice of swarm behavior development typically 
focuses on individual behaviors and low-level interactions [|3]. 
This approach forces developers to constantly ‘reinvent the 
wheel’ to fit well-known algorithms into new applications, 
resulting in a slow and error-prone development process. 

To promote code reuse, two general approaches are possible. 
The first approach is the development of software libraries that 
encapsulate certain algorithms. While this has the advantage of 
leveraging pre-existing frameworks and tools, it falls short of 
screening the user from unnecessary detail, such as non-trivial 
compilation configuration or language-specific boilerplate. 

The second approach is the creation of a domain-specific 
language (DSL) exposing only the relevant aspects of the 
problem to solve. A well-designed DSL shapes the way a sys¬ 
tem is conceived, by offering powerful abstractions expressed 
through concise constructs. 
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In this paper, we argue that a DSL is an indispensable 
tool towards the deployment of real-world robot swarms. 
The dynamics of robot swarms are made complex by the 
presence of both spatial aspects (body shape, sensing, actu¬ 
ation) and networks aspects (message loss, volatile topology). 
Additionally, to render the production of large-scale swarms 
affordable, the robots suffer from significant limitations in 
terms of computational power, especially when compared with 
robots designed to act alone. Thus, a DSL for robot swarms 
has the potential to act as a platform that (i) Filters the low- 
level details concerning space and networking, in an efficient, 
resource-aware fashion; (ii) Offers a coherent abstraction of 
the system; (Hi) Acts as common platform for code reuse and 
benchmarking. 

In this paper, we present Buzz, a novel DSL for robot 
swarms. To drive the design of Buzz, we identified key 
requirements a successful programming language for swarm 
robotics must meet. 

First, as mentioned, the language must allow the program¬ 
mer to work at a suitable level of abstraction. The complexity 
of concentrating on individual robots and their interactions, 
i.e., a bottom-up approach, increases steeply with the size 
of the swarm. Conversely, a purely top-down approach, i.e., 
focused on the behaviour of the swarm as a whole, might 
lack expressive power to fine-tune specific robot behaviors. We 
believe that a language for robot swarms must combine both 
bottom-up and top-down primitives, allowing the developer to 
pick the most comfortable level of abstraction to express a 
swarm algorithm. 

Second, the language must enable a compositional ap¬ 
proach, by providing predictable primitives that can be com¬ 
bined intuitively into more complex algorithms and constructs. 

Third, the language must prove generic enough to (i) express 
the most common algorithms for swarm coordination, such as 
flocking, task allocation, and collective decision making; and 
(ii) support heterogeneous swarms. 

Fourth, the run-time platform of the language must ensure 
acceptable levels of scalability (for increasing swarm sizes) 
and robustness (in case of temporary communication issues). 
Currently, the management of the low-level aspects and corner 
cases concerning these issues constitutes a sizable portion of 
the development process of swarm behaviors. Alleviating this 
burden with a scalable and robust run-time platform is crucial 
for real-world deployment of swarm behaviors. 

The main contribution of this paper is the design and 
implementation of Buzz, a programming language that meets 
the requirements discussed above. Buzz is released as open- 
source software under the MIT license. It can be downloaded 
at http: //the . swarming.buzz/. 
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The text is organized as follows. In Sec. [n] we present the 
design principles we followed. In Sec. [In] we introduce the 


Buzz syntax. In Sec. IV we illustrate the run-time platform. 
In Sec. [V] we report a number of scripts meant to showcase 
the capabilities of Buzz, in particular its conciseness and 


generality. In Sec. VI we analyze the scalability and robustness 
of the Buzz run-time. In Sec. m we discuss related work, 
outlining similarities and differences of Buzz with respect to 
existing languages and frameworks. Finally, in Sec. VIII we 
draw concluding remarks. 


II. Design Principles 

The design of Buzz was based on a set of high-level 
principles, that are described in the following. 

Discrete swarm, step-wise execution. A swarm is considered 
as a discrete collection of devices, each running the Buzz 
virtual machine (BVM), and executing the same Buzz script. 
Script execution proceeds independently on each robot in a 
step-wise fashion. Each time-step is divided in five phases: 

1) Sensor readings are collected and stored in the BVM; 

2) Incoming messages are collected and processed by the 
BVM; 3) A portion of the Buzz script is executed; 4) The 
messages in the BVM output queue are sent (as many as 


possible, according to the available payload size; see Sec. IV i; 
5) Actuator values are collected from the BVM state and 
applied. The length of a time-step is constant over the life¬ 
time of the script, although it does not need to be the same 
for every robot. If the execution time of a step is shorter than 
the allotted time, the robot sleeps for a period. If the execution 
is longer, a warning message is printed on the screen and the 
execution proceeds. 

Predictable and composable syntax. Buzz employs a simple, 
imperative syntax inspired by languages such as Python, Lua, 
and JavaScript. While this syntax ensures a short learning 
curve, it also allows for predictable and composable scripts. 
By predictable , we mean that a programmer can easily infer 
the results of the execution of a program by reading its code. 
Composability refers to the ability to structure a complex 
program into simpler elements, such as functions, classes, etc. 
that can later be used as modules. 

Support for heterogeneous robots. Buzz is explicitly de¬ 
signed to support heterogeneous robot swarms. To this aim. 
Buzz is conceived as an extension language, that is, a lan¬ 
guage that exports and enhances the capabilities of an already 
existing system. This design choice allows one to stack the 
Buzz run-time on top of well-known single-robot frameworks 
such as ROS^j OROCOS 3 or YARP0 The Buzz syntax and 
primitives are minimal, concise, and powerful; the programmer 
can add new primitives and constructs that link to relevant 
features of the underlying system. 

Swarm-level abstraction. One of the novel aspects of Buzz is 
the ability to manage swarms of robots. The concept of swarm 
is a first-class language object Q. Swarms can be created 
and disbanded; new swarms can be created as a result of an 


1 http://www.ros.org/ 

2 http ://w w w.orocos. org/ 
’http://wiki.icub.org/yarp/ 


operation of intersection, union, or difference between two 
pre-existing swarms. Each swarm can be atomically assigned 
operations to perform. Swarms can be employed to encode 
complex task coordination strategies. 

Situated communication. Each robot is assumed to be 
equipped with a device capable of situated communication j5). 
Such device broadcasts messages within a limited range and 
receives messages from neighboring robots in direct, unob¬ 
structed line-of-sight. Upon receipt of a message, a robot 
also detects the relative distance and angle of the message 
sender. Situated communication has been used extensively in 
swarm robotics to achieve global coordination in algorithms 
for, e.g., pattern formation [6j. flocking [7j, exploration (8), 
and task allocation ||9j. This communication modality can be 
achieved on-hardware with robots such as the Kilobot 01- 
the e-puck (TT}, and the marXbot 03- although with lim¬ 
ited payload size, and a dedicated module for low-cost 3D 
communication was proposed in 03). Alternatively, situated 
communication can be satisfactorily realized through WiFi and 
GPS (for outdoor scenarios) or tracking systems such as Vicon 
(for indoor scenarios). 

Information sharing. Buzz provides two ways for robots 
to share information: virtual stigmergy and neighbor queries. 
Virtual stigmergy is a data structure that allows the robots in 
a swarm to globally agree on the values of a set of variables. 
From an abstract point of view, virtual stigmergy is akin to 
a distributed key-value storage. Among its many potential 
applications, this structure may be employed to coordinate 
task execution, e.g., mark the tasks that have already been 
completed and/or share progress on the uncompleted ones. 
Neighbor queries allow a robot to inquire its direct neighbors 
on the value of a certain variable. Upon receiving a request, 
the neighbors reply with the current value of the variable; 
these replies are then collected into a list by the robot who 
requested the data. Neighbor queries are useful when robots 
must perform local data aggregation, such as calculating 
averages 03 or constructing spatial gradients. 


III. Language Definition 


A. Robot-wise operations and primitive types 

The simplest operations available in Buzz are robot-wise 
operations. These operations are executed by every robot 
individually. Assignments, arithmetic operations, loops and 
branches fall into this category. E.g.: 

# Assignment and arithmetic operation 
a = 3 + 7 

# Loop 

i = 0; while (i < a) i = i + 1 

# Branching 

if (a == 10) i = 0 


Buzz is a dynamically typed language that offers the follow¬ 
ing types: nil, integer, floating-point, string, table, closure, 
swarm, and virtual stigmergy. The nil, integer, floating-point, 
and string types work analogously to other scripting languages 
such as Python or Lua. The swarm and virtual stigmergy types 
are introduced in Sec. III-B and III-D| respectively. 

Tables are the only structured type available in Buzz, and 
they are inspired by the analogous construct in Lua 113 - 
Tables can be used as arrays or dictionaries. 
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# Create an empty table 
t = {} 

# Index syntax, use as array 
t[6] = 5 

# Dot syntax, use as dictionary 
t.b = 9 

# Index syntax, use as dictionary 
t["b"] = 10 


Buzz also supports functions as first-class objects, imple¬ 
mented as closures Two types of closures exist: native 
closures and C closures. Native closures refer to functions 
defined within a Buzz script, while C closures refer to C 
functions registered into the BVM (see Sec. 

# Function definition 

function f(a) { return a } 

# Native closure assignment 
n = f 

# Function call using f. x is set to 9 
x = f (9) 

# Function call using n. x is set to 5 
x = n (5) 

# Native closures can be defined anonymously (a.k.a. lambdas) 

1 = function(a,b) { return a+b } 

x = 1(2,3) # x is set to 5 


IV-Fi. 


The combination of tables and closures allows for the creation 
of class-like structures. Following the object-oriented program¬ 
ming jargon, we refer to functions assigned to table elements 
as methods: 

# Create empty table 
t = {} 

# Add attribute to table 
t.a = 4 

# Add method to table 

# 'self' refers to the table owning the method 

t.m = function(p) { return self.a + p } 

# Method call 

x = t.m(6) # x is set to 10 


B. Swarm management 

Buzz lets the programmer subdivide the robots into multiple 
teams. In Buzz parlance, each team is called a swarm. Buzz 
treats swarms as first-class objects. To create a swarm, the 
programmer must provide a unique identifier, which is known 
and shared by all the robots in the created swarm. The returned 
value is a class-like structure of type swarm. 

# Creation of a swarm with identifier 1 
s = swarm.create(1) 


Once a swarm is created, it is initially empty. To have robots 
join a swarm, two methods are available: select () and 
join (). With the former, the programmer can specify a 
condition, evaluated by each robot individually, for joining 
a swarm; with the latter, a robot joins a swarm uncondition¬ 
ally. To leave a swarm. Buzz offers the analogous methods 
unselect () and leave (). A robot can check whether it 
belongs to a swarm through the method in (). 

# Join the swarm if the robot identifier (id) is even 

# - 'id' is an internal symbol that refers to the 

# numeric id of the robot executing the script 

# - % is the modulo operator 
s.select(id % 2 == 0) 

# Join the swarm unconditionally 
s.join() 

# Leave the swarm if the robot id is greater than 5 
s.unselect(id > 5) 

# Leave the swarm unconditionally 


s.leave() 

# Check whether a robot belongs to s 
if(s.in()) { ... } 


Once a swarm is created, it is possible to assign tasks to it 
through the method exec (). This method accepts a closure 
as parameter. 

# Assigning a task to a swarm 

s.exec(function() { ... }) 


Internally, the closure is executed as a swarm function call. 
This call modality differs from normal closure calls in that 
the current swarm id is pushed onto a dedicated swarm 
stack. Upon return from a swarm function call, the swarm 
stack is popped. When the swarm stack is non-empty, the 
swarm. id () method is defined. If called without arguments, 
it returns the swarm id at the top of the swarm stack (i.e., the 
current swarm id); if passed an integer argument n > 0, it 
returns the n-th element in the swarm stack. Besides making 
the swarm, id () command possible, the swarm stack is 
instrumental for neighbor operations (see Sec. IV-Di. 

The programmer can create new swarms that result from 
operations on pre-existing swarms. Four such operations are 
available: intersection, union, difference, and negation. The 
first three operations act on two swarms: 


# a, b are swarms defined earlier in the script 

# Create new swarm with robots belonging to both a and b 

# The first argument is a unique swarm identifier 
i = swarm.intersection(100, a, b) 

# Create new swarm with robots belonging to a or b 

u = swarm.union(101, a, b) 

# Create new swarm with robots belonging to a and not to b 
d = swarm.difference(102, a, b) 


The fourth operation, negation, is encoded in the others () 
method and it creates a new swarm that contains all the robots 
that do not belong to a given swarm: 

# Create a new swarm n as the negation of swarm s 
n = s.others(103) 


C. Neighbor operations 

Buzz offers a rich set of operations based on the neigh¬ 
borhood of a robot. These operations include both spatial and 
communication aspects. 

The neighbors structure. The entry point of all neighbor 
operations is the neighbors structure. For each robot, this 
structure stores spatial information on the neighbors within 
communication range. The structure is updated at each time 
step. It is internally organized as a dictionary, in which the 
index is the id of the neighbor and the data entry is a tuple 
(distance, azimuth, elevation). 

Iteration, transformation, reduction. The neighbors 
structure admits three basic operations: iteration, transfor¬ 
mation, and reduction. Iteration, encoded in the method 
foreach(), allows the programmer to apply a function 
without return value to each neighbor. For instance, to print 
the data stored for each neighbor, one could write: 

# Iteration example (rid is the neighbor's id) 

neighbors.foreach( 

function(rid, data) { 

print("robot ", rid, ": ", 

"distance = ", data.distance, ", " 
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"azimuth = ", data.azimuth, ", " 
"elevation = ", data.elevation) }) 


Transformation, encoded in the method map (), applies a 
function with return value to each neighbor. The return value is 
the result of an operation on the data associated to a neighbor. 
The end result of mapping is a new neighbors structure, 
in which each neighbor id is associated to the transformed 
data entries. For example, to transform the neighbor data into 
cartesian coordinates, one could proceed as follows: 


# Transformation example 

cart = neighbors .map( 
function (rid, data) { 
var c = {} 

c.x = data.distance * math .cos(data.elevation) * 
math .cos(data.azimuth) 

c.y = data.distance * math .cos(data.elevation) * 
math .sin(data.azimuth) 

c.z = data.distance * math .sin(data.elevation) 

return c }) 


Reduction, encoded in the method reduce (), applies a 
function to each neighbor to produce a single result. For 
instance, this code sums the cartesian vectors calculated in 
the previous example: 

# Reduction example, accum is a table 

# with values x, y, and z, initialized to 0 
result = cart.reduce (function (rid, data, accum) { 

accum.x = accum.x + data.x 
accum.y = accum.y + data.y 
accum.z = accum.z + data.z 
return accum 
}, {x=0, y=0, z=0}) 


Filtering. It is often useful to apply the presented operations 
to a subset of neighbors. The filter!) method allows 
the programmer to apply a predicate to each neighbor. The 
end result of the filter () method is a new neighbors 
structure storing the neighbors for which the predicate (a 
function) was true. For instance, to filter the neighbors whose 
distance is within 1 m from a robot, one could write: 


D. Virtual stigmergy 

Virtual stigmergy is a data structure that allows a swarm 
of robots to share data globally. Essentially, virtual stig¬ 
mergy works as a distributed tuple space analogous to 
Linda [ 1_7|. Three methods are available: create (), put (), 
and get (). As the names suggest, create () is a method 
that creates a new virtual stigmergy structure, while put () 
and get () access the structure, writing or reading (key, 
value) entries. 

# Create a new virtual stigmergy 

# A unique id (1 here) must be passed 
v = stigmergy .create(1) 

# Write a (key, value) entry into the structure 
v.put("a", 6) 

# Read a value from the structure 
x = v. get (" a " ) 


A virtual stigmergy structure can handle only a subset of 
the primitives types: integer, floating-point, string, and table. 
These types can be used either as keys or values. 

The name virtual stigmergy derives from the indirect, 
environment-mediated communication of nest-building insects 
such as ants and termites [18]. The key idea in natural 
stigmergy is that environmental modifications to organize the 
environment occur in a step-wise fashion, whereby a modifica¬ 
tion performed by an individual causes a behavioral response 
in another individual, without the two individuals ever directly 
interacting. From the point of view of the programmer, virtual 
stigmergy works as a virtual shared environment: a robot 
modifies an entry, and this modification triggers a reaction 
in another robot without the two having to interact directly. 

As shown in Sec.[V] virtual stigmergy is a powerful concept 
that enables the implementation of a large class of swarm 
behaviors. 


IV. Run-Time Platform 
A. The Buzz virtual machine 


# Filtering example 

onemeter = neighbors .filter (function (rid, data) { 

# We assume the distance is expressed in centimeters 
return data.distance < 100 }) 


Another common necessity is filtering neighbors by their 
membership to a swarm. The kin () method returns a 
neighbors structure that contains the robots that belong 
to the same top-of-the-stack swarm as the current robot. The 
nonkin () method returns the complementary structure. An 
example application for these methods is offered in Sec. |V] 
Communication. Another use for the neighbors structure 
is to exchange and analyze local data. To make this possible. 
Buzz offers two methods: broadcast () and listen (). 
The former allows the robot to broadcast a (key, value) 
pair across its neighborhood. The latter takes two inputs: 
the key to listen to, and a listener function to execute 
upon receiving a value from a neighbor. The BVM executes 
the listener whenever data is received until the method 
neighbors . ignore (key) is called. As an example, in 
Sec. VI we report an experiment in which a robot swarm forms 
a distance gradient from a robot acting as source. 


The run-time platform of Buzz is based on a custom, stack- 
based virtual machine written entirely in C. The organization 
of the modules composing the VM is depicted in Fig. [T] 
The implementation of a new VM is motivated by the design 
choices in Buzz. In particular, the integration of swarm man¬ 
agement and virtual stigmergy into a VM for a dynamically- 
typed, extensible language forced us to find dedicated solutions 
for data representation, stack/heap management, and byte code 
encoding. The specifics on these aspects are purely technical 
and go beyond the scope of this paper. A notable fact about the 
BVM is its tiny size (12 KB) which fits most robots currently 
in use for swarm robotics research. 

At each time step, the BVM state is updated with the latest 
sensor readings. Sensor readings are typically stored in the 
heap as data structures (e.g., tables). Incoming messages are 
then inserted in the BVM, which proceeds to unmarshal them 
and update the relevant modules. Subsequently, the interpreter 
is called to execute a portion of the script. At the end of this 
phase, the updated actuator data is read from the BVM heap 
and part of the messages in the outbound queue are sent by 
the underlying system. 
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Sensor data Actuator data 


Fig. 1. The structure of the Buzz virtual machine. 


B. Code Compilation 

The compilation of a Buzz script involves two tools: a com¬ 
piler called buzzc and an assembler/linker called buzz asm. 
The former is a classical recursive descent parser that generates 
an annotated object file in a single pass. The latter parses the 
object file, performs the linking phase, and generates the byte 
code. The compilation process is typically performed on the 
programmer’s machine, and the generated byte code is then 
uploaded on the robots. 

Because Buzz is an extension language, it is likely for the 
compiler to encounter unknown symbols. This typically occurs 
when robots with different capabilities are employed. For in¬ 
stance, flying robots may provide a f ly_to () command for 
motion, while wheeled robots may provide a set_wheels () 
command (see also Sec. |IV-F[ >. 

By default, the compiler treats unknown symbols as global 
symbols. Only at run-time, when a symbol is accessed, its 
actual value is retrieved. In case the symbol is unknown at 
run-time, its value is set to nil. This mechanism provides 
a flexible way to write scripts that can work on robots with 
diverse capabilities. As a simple example, to create a swarm 
that contains all the flying robots, it is enough to write: 

aerial = swarm.create(1) 
aerial.select(fly_to) 


C. Swarm management 

The management of swarm information is performed trans¬ 
parently by the BVM. Essentially, each robot maintains two 
data structures about swarms: the first structure concerns the 
swarms of which the robot is a member; the second stores data 
regarding neighboring robots. The membership management 
mechanisms are loosely inspired by CYCLON [ 191. 
Membership management. Every time a 
swarm. create () command is executed, the BVM 
stores the identifier of the created swarm into a dedicated 
hash table, along with a flag encoding whether the robot 
is a member of the swarm (1) or not (0). Upon joining 
a swarm, the BVM sets the flag corresponding to the 


swarm to 1 and queues a message <SWARM_JOIN, 
robot_id, swarm_id>. Analogously, when a robot 
leaves a swarm, the BVM sets the corresponding flag to 
0 and queues a message <SWARM_LEAVE, robot_id, 
swarm_id>. Because leaving and joining swarms is not 
a particularly frequent operation, and motion constantly 
changes the neighborhood of a robot, it is likely for a 
robot to encounter a neighbor for which no information is 
available. To maintain everybody’s information up-to-date, 
the BVM periodically queues a message <SWARM_LIST, 
robot_id, swarm_id_list> containing the complete 
list of swarms to which the robot belongs. The frequency of 
this message is chosen by the developer when configuring 
the BVM installed on a robot. 

Neighbor swarm data. The BVM stores the information in a 
hash map indexed by robot id. Each element of the hash map is 
a (swarm_id_list, age) pair where swarm_id_list 
corresponds the list of swarms of which the robot is a member, 
and age is a counter of the time steps since the last reception 
of a swarm update. Upon receipt of a swarm-related message 
(i.e., SWARM_JOIN, SWARM_LEAVE, SWARM_LIST), the 
BVM updates the information on a robot accordingly and 
zeroes the age of the entry. This counter is employed to 
forget information on robots from which no message has been 
received in a predefined period. When the counter exceeds a 
threshold decided when configuring the BVM, the information 
on the corresponding robot is removed from the structure. 
This simple mechanism allows the robots to commit memory 
storage on active, nearby robots while avoiding waste of 
resources on unnecessary robots, such as out-of-range or dam¬ 
aged robots. In addition, this mechanism prevents excessive 
memory usage when the swarm size increases. 

Message queue optimizations. To minimize the bandwidth 
required for swarm management, the BVM performs a number 
of optimizations on the queue of swarm-related outbound 
messages. 

• If a SWARM_LIST message is queued, the information 
contained in the message is more up-to-date than any 
other message in the queue. Thus, all the queued mes¬ 
sages are removed and only the latest SWARM_LIST 
message is kept. 

• If a SWARM_JOIN message is queued, three situations 
can occurj^jfz) The queue does not contain any message 
regarding the same swarm id; (ii) The queue contains an 
older SWARM_LIST message; or (iii) The queue contains 
an older SWARM_LEAVE message for the same swarm id. 
In the first case, the SWARM_JOIN message is kept in the 
queue. In the second case, the SWARM_JOIN message 
is dropped, the SWARM_LIST message is kept in the 
queue, and the swarm id of the SWARM_JOIN message 
is added to the list if not already present. In the third 
case, the SWARM_LEAVE message is dropped and the 
SWARM_JOIN message is kept in the queue. 

• If a SWARM_LEAVE message is queued, three situations 
can occur: (i) The queue does not contain any message 


4 If an older SWARM_JOIN message for the same swarm id is present, the 
new message is discarded. 
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regarding the same swarm id; (ii) The queue contains an 
older SWARM_LIST message; or (iii) The queue contains 
an older SWARM_JOIN message for the same swarm id. 
In the first case, the SWARM_LEAVE message is kept 
in the queue. In the second case, the SWARM_LEAVE 
message is dropped, the SWARM_LIST message is kept 
in the queue, and the swarm id of the SWARM_LEAVE 
message is removed from the list if present. In the third 
case, the SWARM_JOIN message is dropped and the 
SWARM_LEAVE message is kept in the queue. 

D. Neighbor operations 

Neighbor operations involve the collection and manipulation 
of data about nearby robots. 

Neighbor data handling. Neighbor information is stored in 
a sparse array indexed by the robot id of a neighbor. Each 
entry is a tuple containing the id of the neighbor, its distance, 
azimuth, and elevation angles expressed with respect to the 
robot’s frame of reference. 

Neighbor data collection. Data collection involves the use of 
situated communication devices, as discussed in Sec. [II] At 
each time step, a robot broadcasts a message <robot_id>. 
Upon receiving this message, neighboring robots use their 
situated communication devices to detect the distance, azimuth 
and elevation of the sending robot. The neighbors structure 
is cleared and reconstructed at each time step, to ensure 
that the data is constantly up-to-date. This operation is not 
expensive, because typically the number of neighbors of a 
robot is lower than 10. 

Neighbor queries. Neighbor queries allow robots 
to inquire and share information on the value of a 
specific symbol. When a robot executes the command 
neighbors . listen (key, listener), the BVM 
stores the passed listener in a map indexed by key. 
Whenever the robot processes a message identified by key, the 
BVM executes the corresponding listener. The command 
neighbors . ignore (key) removes listener from 
the map. The method neighbors.broadcast (key, 
value) queues a message <key, value>. If a message 
with the same key is already present in the output queue, 
the BVM keeps the most recent one. 


E. Virtual stigmergy 

Virtual stigmergy stmctures are stored by the BVM in a 
sparse array indexed by the id provided in the Buzz script. 
Each entry of the sparse array is a separate virtual stig¬ 
mergy structure. Internally, a virtual stigmergy structure is a 
hash map that stores tuples (key, value, timestamp, 
robot_id) where key is a Buzz primitive type that iden¬ 
tifies the entry, value is a primitive type that contains the 
value of the entry, timestamp is a Lamport clock [20"| 
used to impose a temporal ordering on the entry updates, and 
robot_id is the id of the robot that last changed the entry. 
Writing into a virtual stigmergy structure. When a 
robot writes a new value into a virtual stigmergy struc¬ 
ture, the BVM first creates or updates the local en¬ 
try in the hash map. Subsequently, the BVM queues 


a message <VSTIG_PUT, vstig_id, key, value, 
timestamp, robot_id>. Nearby robots, upon receipt of 
the message, check whether its timestamp is higher than the 
locally known one. If this is the case, the robots propagate the 
message. Otherwise, they ignore it. It might happen that two 
robots advertise an update on the same key with the same 
timestamp. When this happens, a user-defined conflict- 
solver function is called. This function is given the conflicting 
entries as parameters, and must return an entry as result. The 
resulting entry can be either picked as-is from the input ones, 
or be a newly created one. To help resolve conflicts, each 
input entry also contains a robot_id field storing the robot 
id that generated the entry. If no conflict solver is specified by 
the user, the entry with the highest robot id is propagated. A 
further user-defined function is executed by the robot that lost 
the conflict. By default, this function does nothing; however, 
in some applications a robot might need to react, e.g. retry 
sending its update. An example usage of these functions is 


reported in Sec. V-B 


Reading from a virtual stigmergy structure. When a robot 
R1 reads a value from a virtual stigmergy structure, the 
locally known value is returned by the BVM. Subsequently, 
the BVM queues a message <VSTIG_GET, vstig_id, 
key, valuel, timestampl, robot_idl> to inquire 
nearby robots on whether the local entry is up-to-date or 
not. Upon receiving this message, a robot R2 checks its 
internal data structure. If R2 knows more up-to-date informa¬ 
tion, it replies with a message <VSTIG_PUT, vstig_id, 
key, value2, timestamp2, robot_id2> contain¬ 
ing its local version of the entry. If, instead, R2 possesses 
older information, its BVM updates the entry and then 
broadcasts a message <VSTIG_PUT, vstig_id, key, 
valuel, timestampl, robot_idl>. This mechanism 
allows robots to automatically update information after tem¬ 
porary disconnections or when random message loss occurs. 
Message queue optimizations. The fact that messages are sent 
only when an entry is written or read ensures that maximum 
resources are concentrated on ‘hot’ data. This allows the robots 
to avoid expensive updates of the entire tuple space. In this 
way, a virtual stigmergy structure can grow in size if necessary, 
knowing that minimal overhead is necessary to keep ‘hot’ data 
up-to-date. However, the fact that each access to a virtual 
stigmergy stmcture entails the production of a message can 
quickly fill the message queue. To avoid this problem, when a 
message is queued, the BVM checks for existing messages in 
the outbound queue that refer to the same entry in the same 
virtual stigmergy structure, and only keeps the most up-to-date 
message. 


F. Integrating and Extending Buzz 

As an extension language, Buzz provides the necessary 
mechanisms to add new commands and add data structures 


that export parts of an underlying system (e.g. ROS 1211). 
Adding new data structures. Sensor readings are a common 
aspect that must be integrated with Buzz. Typically, this is 
realized by adding dedicated data structures (e.g., tables) to the 
BVM. For instance, the e-puck is equipped with 8 proximity 
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sensors placed in a ring around the robot body. The C code to 
create a Buzz table that contains these values is as follows: 

/* The Buzz virtual machine, assumed already initialized */ 
buzzvm_t vm; 

/* The proximity readings, assumed already filled */ 

int prox[8]; 

/* Create a new Buzz table for the proximity readings */ 
buzzvm_pusht(vm); 

buzzobj_t pt = buzzvm_stack_at(vm, 1); 
buzzvm_pop(vm); 

/* Store the proximity readings in the table */ 
for(int i = 0; i < 8; ++i) { 

buzzvm_push(pt); /* push table */ 

buzzvm_pushi(vm, i); /* push table index */ 

buzzvm_pushi(vm, prox[i]); /* push prox reading */ 
buzzvm_tput(vm); /* store in table */ 

} 

/* Store the table as the global symbol "prox" */ 
buzzvm_pushs(vm, buzzvm_string_register(vm, "prox")); 
buzzvm_push(pt); 
buzzvm_gstore(pt); 


In Buzz, one could then write the following: 

if(prox[0] > 100 or prox[7] > 100) { 

# obstacle in front, turn around 

} 

Adding new commands. Adding new commands allows a 
programmer to extend Buzz with new capabilities. External C 
functions are integrated with Buzz as C closures. For instance, 
the code to integrate a function that sets the e-puck wheel 
speeds is as follows (error checking is omitted for brevity): 


int set_wheels(buzzvm_t vm) { 

/* Read arguments */ 
buzzvm_lload(vm, 1); 
buzzvm_lload(vm, 2); 

int leftwheel = buzzvm_stack_at(vm, 2); 
int rightwheel = buzzvm_stack_at(vm, 1); 

/* Set wheel speed using low-level e-puck 

library */ 

/* Return no value to Buzz */ 
return buzzvm_ret0(vm); 


/* Register function as global symbol */ 

buzzvm_pushs(vm, buzzvm_string_register(vm, "set_wheels")); 
buzzvm_pushcc(vm, buzzvm_function_register(vm, set_wheels)); 
buzzvm_gstore(vm); 


As a result, in Buzz one could write: 


# Set e-puck wheel speeds 
set_wheels(10.0, 5.0) 

Calling Buzz functions from C. It is sometimes necessary 
to call a (native or C) closure from C code. This happens, for 
instance, when the execution loop is managed outside Buzz. In 
this case, a Buzz script is typically organized in functions such 
as init (), step (), and destroy (). These functions are 
called by the underlying system when necessary. As a simple 
example, let us take the increment function: 

# Buzz function that accepts a single argument 

function inc (x) { return x + 1 } 

To call it from C code, one needs to push its argument on the 
stack (an integer, in this example) and then call the function 

buzzvm_function_call(): 

/* Push the function argument on the stack */ 
buzzvm_pushi(vm, 5); 

/* Call the function with: 

* 1. The VM data 

* 2. The function name 

* 3. The number of parameters passed 
*/ 

buzzvm_function_call(vm, "inc", 1); 


V. Examples 

The objective of this section is to showcase Buzz, by 
providing examples of common swarm algorithms for motion 
and task coordination. These examples show how to build 
complex swarm behaviors starting from simpler primitives, 
and demonstrate the generality and composability of Buzz. The 
examples are also designed to suggest how a library of reusable 
swarm behaviors could be constructed using Buzz. The scripts 
were tested with ARGoS p2| , an accurate, physics-based 
simulator that includes models for SpirQ a commercial quad- 
rotor robot. 

A. Motion and Spatial Coordination 

In heterogeneous swarms, the presence of robots with 
diverse motion means can enhance the capabilities of the 
swarm (23 ]. Buzz does not offer native motion primitives, 
leaving the designer with the freedom to set ones that are most 
suitable for each robot. In this section, we assume that every 
robot is endowed with a primitive goto (), which takes a 2D 
direction as input in the form of a table {x, y}. The direction 
is then transformed into low-level actuation accordingly to the 
specific motion means of a robot (e.g., wheels, propellers). 

Pattern formation © is a basic swarm behavior that has 
been employed in several applications including flocking |7J 
and area coverage (8). One of the most common approaches, 
and the one we show here, is to implement pattern formation 
through virtual physics |6|. Essentially, every robot is consid¬ 
ered as a charged particle immersed in a potential field, which 
is ‘virtual’ because it is calculated from neighbor positioning 
data. The direction vector of each robot is calculated as 
the weighted sum of the virtual forces that derive from the 
interaction of a robot with its neighbors. We employ the 
following formula 0J to calculate the magnitude of the virtual 
force f„ due to a neighbor n: 



where d n is the current distance between the robot and its 
neighbor n, 6 is the target distance, and e is a gain. The 
direction vector a robot must follow is calculated as the 
average of the vectors of the virtual forces f„ : 

1 N 

f = jv£ f »- 

n= 1 

The neighbors structure provides a natural way to im¬ 
plement this behavior. First, one must implement the function 
that calculates |f„|: 

# Virtual force parameters (manually fitted) 

DELTA = 50. 

EPSILON = 2700. 

# Virtual force magnitude 

function force_mag(dist, delta, epsilon) { 
return -(epsilon / dist) * 

((delta / dist)"4 - (delta / dist)"2) 

} 


5 http://www.pleiades.ca 










(a) Hexagonal pattern formation. 

Fig. 2. ARGoS screenshots of the swarm behaviors presented in Sec. |V-A| 



(b) Segregation. 


Next, we need a function to calculate f„ from the positional 
information of a neighbor. This function is then used in 

neighbor. reduce () to calculate f: 

# Virtual force accumulator 

function force_sum(rid, data, accum) { 

var fm = force_mag(data.distance, DELTA, EPSILON) 
accum.x = accum.x + fm * math.cos(data.azimuth) 
accum.y = accum.y + fm * math.sin(data.azimuth) 
return accum 

} 

# Calculates the direction vector 

function direction() { 

var dir = neighbors.reduce(force_sum, {x=0,y=0}) 
dir.x = dir.x / neighbors.count() 
dir.y = dir.y / neighbors.count() 
return dir 

} 

# Executed at each step 

# The loop is assumed managed outside Buzz 

function step() { 
goto(direction()) 

} 


Fig. 2a reports an ARGoS screenshot depicting the structure 
achieved by the robots after 30 seconds of simulated time. 


B. Collective Decision-Making 

Collective decision-making is an important aspect in multi¬ 
robot coordination. In this section, we concentrate on one 
of the simplest and widespread behaviors in this class—the 
barrier. A barrier is a synchronization mechanism that allows 
a swarm to wait until a sufficient number of robots are ready 
to proceed. Quorum sensing has been proposed as a way 
to achieve this behavior |24| . Quorum sensing refers to the 
progressive build-up of a chemical in cell colonies. When the 
cells detect that the concentration of such chemical exceeds a 
threshold, a new behavior is triggered. 

Virtual stigmergy offers a mean to implement quorum sens¬ 
ing. Every time a robot wants to mark itself as ready, it puts a 
pair (id, 1) in the virtual stigmergy structure, where id is 
a robot’s numeric id. The size () method returns the number 
of tuples in the virtual stigmergy, which here corresponds to 
the count of ready robots. When this count reaches the swarm 
size (or another application-dependent threshold value), the 
robots collectively trigger the next phase. 


BARRIER_VSTIG = 1 

# Function to mark a robot ready 

function barrier_set () { 

# Create a vstig 

barrier = stigmergy .create(BARRIER_VSTIG) 

} 

# Function to mark a robot ready 

function barrier_ready() { 

barrier.put(id, 1) 

} 

# Function to wait for everybody to be ready 

function barrier_wait(threshold) { 

while (barrier.size() < threshold) barrier.get(id); 

} 


An example usage of the barrier is presented in Sec. 


V-C 


C. Separation into Multiple Swarms 

Segregation is a basic motion behavior whereby a group of 
robots divides into two or more subgroups. A possible way 
to implement this behavior in Buzz consists of defining two 
swarms, and use pattern formation to impose a short distance 
between kin robots, and a long one between non-kin ones. The 
following modifications to the pattern formation algorithm in 



The decision on which group a robot belongs to depends on 
the application. In the following, we concentrate on the case 
in which two different targets are present in the environment. 
Each target is marked by a colored light—one red, one blue. 
The Spiri is equipped with a frontal camera that can detect 


# A numeric id for the barrier virtual stigmergy 
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a target and its color. We assume that not all of the robots 
are capable of detecting the target, due to obstructions or 
sensor range limitations. The uninformed robots must rely 
on the information shared by the informed robots to pick the 
closest target. A possible solution to achieve this is employing 
a virtual stigmergy structure, in which each robot advertises 
its distance to the closest target and its color: 

NUM_ROBOTS =10 

MAX_DISTANCE = 10000 #100 meters 
TARGET_VSTIG = 2 

# Create virtual stigmergy 

targetvstig = stigmergy.create(TARGET_VSTIG) 

# Get target data 
var mytargetdata = {} 
if(camera.targetdata) 

# Can see the target directly 
mytargetdata = camera.targetdata 
targetvstig.put(id, mytargetdata) 
targetfound = 1 

else { 

# Can't see the target directly 

mytargetdata.dist = MAX_DISTANCE 

mytargetdata.color = nil 

mytargetdata.closest = nil 
targetfound = nil 

} 

# Keep monitoring neighbors until everybody 

# advertises a distance 
while(not targetfound) { 

targetfound = 1 

mytargetdata = neighbors.reduce( 
function(rid, rdata, accum) { 
var d = targetvstig.get(rid) 
if(d != nil) { 

if(d.dist < DISTANCE_MAX) { 

if(accum.dist > rdata.distance + d.dist) { 

accum.dist = rdata.distance + d.dist 

accum.closest = rid 

accum.color = d.color 

} 

} 

else targetfound = nil 

} 

else targetfound = nil 
return accum 
}, mytargetdata) 

# Advertise choice 
targetvstig.put(id, mytargetdata) 

# Neighbors done? 

if(targetfound) barrier_ready() 

} 

# Wait for others to finish 
barrier_wait(NUM_ROBOTS); 

# When we get here, everybody has picked a target 


Once the choice is done and the barrier is overcome, the 
robots form two swarms and move accordingly: 

sred = swarm. create(COLOR_RED) 

sred.select(mytargetdata.color == COLOR_RED) 

sblue = swarm. create(COLOR_BLUE) 

sblue.select(mytargetdata.color == COLOR_BLUE) 

while(1) { 

sred.exec (function () { goto(direction()) }) 

sblue.exec (function () { goto(direction()) }) 

} 

Fig. [Zbjreports an ARGoS screenshot depicting the structure 
achieved by the robots after 2 minutes of simulated time. 

VI. Experimental Evaluation 
In this section, we analyze the scalability and robust¬ 
ness of the Buzz run-time. We focus our analysis on two 
subsystems, virtual stigmergy and neighbor queries, because 
of their key role in swarm coordination. The evaluation is 
conducted through simulations in ARGoS with the ground- 
based marXbot robot HD- 


Experimental setup. Our experimental setup consists of a 
square arena of side L in which N robots are scattered. The 
coordinates (at, y) of each robot are chosen uniformly from 
U{— E/2, L/2)0 We define the robot density D as the ratio 
between the area occupied by all the robots and the total area 
of the arena. To ensure comparable conditions across different 
choices of N, we keep the density constant (D = 0.1) and 
calculate L with: 


D = 


NirR 2 

~1X~ 


L = 


NnR 2 

D 


where R = 8.5 cm is the radius of a marXbot. We focus our 
analysis on two parameters that directly affect the properties 
that we intend to analyze: (i) The number of robots N, which 
impacts scalability; and (ii) The message dropping probability 
P, which affects robustness and accounts for an important, 
unavoidable phenomenon that influences the efficiency of 
current devices for situated communication. For N, we chose 
{10,100,1000}; for P, we chose {0,0.25,0.5,0.75,0.95}. 
Each experimental configuration (N, P) was tested 100 times. 
Virtual stigmergy. To analyze the efficiency of virtual stig¬ 
mergy, we devised an experiment in which the robots must 
agree on the highest robot id across the swarm. This experi¬ 
ment is representative of a wide class of situations in which a 
robot swarm must agree on the maximum or minimum value 
of a quantity (e.g., sensor reading). As performance measure, 
we employed the number of time steps necessary to reach 
global consensus. We report in Fig. [3] the script we executed 
and the data distribution we obtained. Our results indicate that, 
up to P = 0.75, the number of time steps necessary to reach 
consensus is affected weakly by N, and practically unaffected 
by P. Interestingly, for (N = 1000, P = 0.75), consensus is 
reached in at most 15 time steps (a time step corresponds to 
0.1 s in our simulations). This positive result can be explained 
by noting that, with P = 0.75, 3 messages out of 4 are lost; 
however, the uniform distribution of the robots ensures that, on 
average, each robot has more than 3 neighbors. Thus, messages 
can still flow throughout the network. The effect of packet 
dropping is apparent for very pessimistic values (P = 0.95). 
Neighbor queries. To analyze the performance of neighbor 
queries, we devised an experiment in which the robots must 
construct a distance gradient from a robot acting as source. 
This experiment is representative because the formation of 
gradients is a fundamental coordination mechanism in swarm 
behaviors. As performance measure, we employ the time 
necessary for every robot to estimate its distance to the source. 
The script and the data plot are reported in Fig. [4] The 
dynamics are analogous to virtual stigmergy: convergence 
time depends weakly on N and is unaffected by P up to 
P = 0.75; for (N = 1000, P = 0.75) convergence is reached 
in a maximum of 13 time steps; for P = 0.95, convergence 
times increase sensibly. Again, this is arguably due to the 
dense distribution of robots, which facilitates the circulation 
of messages across the swarm, thus mitigating the effects of 
message dropping. 


s When a coordinate choice causes physical overlap with already placed 
robots, a new coordinate is picked until no overlap occurs. 
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# Executed at init time 

function init() { 

# Create a vstig 
VSKEY = 1 

vs = stigmergy .create(1) 

# Set onconflict manager 

vs . onconflict (function (k, 1 , r) { 

# Return local value if 

# - Remote value is smaller than local, OR 

# - Values are equal, robot of remote record is 

# smaller than local one 
if (r.data < l.data or 

(r.data == l.data and 
r.robot < 1.robot)) { 
return 1 

} 

# Otherwise return remote value 

else return r 

}) 

# Initialize vstig 
vs_value — id 

vs.put(VSKEY, vs_value) 

} 

# Executed at each time step 

function step() { 

# Get current value 
vs_value = vs.get(VSKEY) 


Fig. 3. Virtual stigmergy performance assessment. The plot reports the me¬ 
dian, max, and min values of the distributions obtained for each experimental 
configuration (N, P). The markers are slightly offset to make them visible. 


VII. Related Work 

Most of the literature in programming languages designed 
for robotics focus on individual robots. Prominent examples 
of this body of work are Willow Garage’s Robot Operating 
System (ROS) (21) , and the event-based language URBI |25|. 
In swarm robotics, SWARMORPH-script (26 ] is a bottom- 
up behavior-based scripting language designed to achieve 
morphogenesis with mobile robots. 

The last decade saw the introduction of the first top- 
down approaches to the development of distributed computing 
systems. Various abstractions and programming languages 
have been proposed in the sensor network community (27). 
A programming methodology inspired by embryogenesis and 
designed for self-assembly applications was proposed in (28) . 
Dantu et al. proposed Karma (29) , a framework that combines 
centralized and distributed elements to perform task allocation 
in a swarm of aerial robots unable to communicate directly. 

Proto (30) is a language designed for “spatial computers,” 
that is, a collection of connected computing devices scattered 


# Constant for infinite distance (500 m) 

DISTANCE_INF = 50000. 

# Executed at init time 

function init() { 
if(id == 0) 

# Source robot 
mydist = 0. 

else { 

# Other robots 

mydist = DISTANCE_INF 

# Listen to other robots' distances 
neighbors .listen("dist_to_source", 

function (vid, value, rid) { 
mydist = math. min( 
mydist, 

neighbors .get(rid).distance + value) 

}) 

} 

} 

# Executed at each time step 

function step() { 

neighbors .broadcast("dist_to_source", mydist) 

} 


Fig. 4. Neighbor query performance assessment. The plot reports the median, 
max, and min values of the distributions obtained for each experimental 
configuration (N, P). The markers are slightly offset to make them visible. 


in a physical space. The spatial computer is modeled as 
a continuous medium in which each point is assigned a 
tuple of values. The primitive operations of Proto act on 
this medium. The LISP-like syntax of Proto is modular by 
design and produces predictable programs. Proto shines in 
scenarios in which homogeneous devices perform distributed 
spatial computation—the inspiration for Buzz’ neighbors 
construct was taken from Proto. However, as a language for 
robotics, Proto presents a number of limitations: (i) As a 
functional language, maintaining state over time is cumber¬ 
some; (ii) Every node handles only single tuples; (iii) Support 
for robot motion is limited; (iv) No explicit support for 
heterogeneous devices is present. Part of these issues have 
been addressed in (JTj. 

Meld (32) is a declarative language that realizes the top- 
down approach by allowing the developer to specify a high- 
level, logic description of what the swarm as a whole should 
achieve. The low-level (communication/coordination) mecha¬ 
nisms that reify the high-level goals, i.e., the how, are left 
to the language implementation and are transparent to the 
developer. The main concepts of the language are facts and 
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rules. A fact encodes a piece of information that the system 
considers true at a given time. A computation in Meld consists 
of applying the specified rules progressively to produce all 
the true facts, until no further production is possible. Meld 
supports heterogeneous robot swarms by endowing each robot 
with facts that map to specific capabilities. A similar concept 
exists in Buzz, with robot-specific symbols (see Sec. |IV-B| i. 
The main limitation of Meld for swarm robotics is the fact that 
its rule-based mechanics produce programs whose execution 
is difficult to predict and debug, and it is thus impossible to 
decompose complex programs into well-defined modules. 

Voltron (33) is a language designed for distributed mobile 
sensing. Voltron allows the developer to specify the logic to 
be executed at several locations, without having to dictate 
how the robots must coordinate to achieve the objectives. 
Coordination is achieved automatically through the use of 
a shared tuple space, for which two implementations were 
tested—a centralized one, and a decentralized one based on the 
concept of virtual synchrony (34). In Buzz, virtual stigmergy 
was loosely inspired by the capabilities of virtual synchrony, 
although the internals of the two systems differ substantially. 
Voltron excels in single-robot, single-task scenarios in which 
pure sensing is involved; however, fine-grained coordination 
of heterogeneous swarms is not possible, because Voltron’s 
abstraction hides the low-level details of the robots. 

VIII. Conclusions and Future Work 

We presented Buzz, a novel programming language de¬ 
signed for large-scale, heterogeneous robot swarms. The con¬ 
tributions of our work include: (i) a mixed paradigm for the 
implementation of robot swarms, which allows the developer 
to specify fine-grained, bottom-up logic as well as reason in 
a top-down, swarm-oriented fashion; (ii) the definition of a 
compositional and predictable approach to swarm behavior 
development; (iii) the implementation of a general language 
capable of expressing the most common swarm behaviors. 

Besides these contributions, we believe that one of the 
most important aspects of Buzz is its potential to become 
an enabler for future research on real-world, complex swarm 
robotics systems. Currently, no standardized platform exists 
that allows researchers to compare, share, and reuse swarm 
behaviors. Inescapably, development involves a certain amount 
of re-coding of recurring swarm behaviors, such as flocking, 
barriers, and creation of gradients. The design of Buzz is 
motivated and nurtured by the necessity to overcome this state 
of affairs. We hope that Buzz will have a lasting impact on 
the growth of the swarm robotics field. 

Future work on Buzz will involve several activities. Firstly, 
we will integrate the run-time into multiple robotics platforms 
of different kinds, such as ground-based and aerial robots. 
Secondly, we will create a library of well-known swarm 
behaviors, which will be offered open-source to practitioners 
as part of the Buzz distribution. This will be the first true 
collection of ‘swarm patterns’, in the classical sense the word 
‘pattern’ assumes in software engineering (35) . Finally, we 
will tackle the design of general approaches to swarm behavior 
debugging and fault detection. These topics have received 


little attention in the literature, and Buzz constitutes an ideal 
platform to study them. In particular, we will study more in 
depth the impact of the network topology on the efficiency of 
message passing, and we will investigate adaptive methods to 
detect and mitigate the issues of unoptimal topologies. 
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